Add debug restart #508
Add debug restart #508
Conversation
|
This is a nice improvement on the HCR failure path. Now that I appreciate the use case better... I can also appreciate that it still leaves say the path in which dev mode restarts the server upon a bootstrap.properties update. Let's think about that more. |
awisniew90
force-pushed
the
debug-restart
branch
5 times, most recently
from
cd61919 to
5ce2066
Compare
bundles/io.openliberty.tools.eclipse.ui/src/io/openliberty/tools/eclipse/DevModeOperations.java
Outdated
Show resolved
Hide resolved
| /** | ||
| * Updates the state of this target for disconnection from the VM. | ||
| */ | ||
| @Override |
There was a problem hiding this comment.
Maybe a comment explaining we don't know here if we're disconnected() because of dev mode restarting the server vs. the JDT debugger HCR failure refreshing the debugger.
| port = parts[1].trim(); | ||
| String lastEntry = null; | ||
|
|
||
| Scanner scan = new Scanner(serverEnv); |
There was a problem hiding this comment.
Turns out we don't need to make this change.
...io.openliberty.tools.eclipse.ui/src/io/openliberty/tools/eclipse/debug/DebugModeHandler.java
Outdated
Show resolved
Hide resolved
...io.openliberty.tools.eclipse.ui/src/io/openliberty/tools/eclipse/debug/DebugModeHandler.java
Outdated
Show resolved
Hide resolved
awisniew90
force-pushed
the
debug-restart
branch
2 times, most recently
from
5c608df to
c95e3ee
Compare
Signed-off-by: Adam Wisniewski <[email protected]>
Signed-off-by: Adam Wisniewski <[email protected]>
|
Just capturing that we reviewed this today and thought it'd be good to get rid of the automatic reconnect on disconnect. We can still have the overloaded reconnect selection button on HCR failure. We also are good with the idea that each Run/Debug config can define its own reconnect/disconnect behavior, so us defining our own is fine from that POV. |
Signed-off-by: Adam Wisniewski <[email protected]>
awisniew90
force-pushed
the
debug-restart
branch
from
c95e3ee to
b33798e
Compare
Signed-off-by: Adam Wisniewski <[email protected]>
Signed-off-by: Adam Wisniewski <[email protected]>
Signed-off-by: Adam Wisniewski <[email protected]>
| Path serverEnvPath = Paths.get(list.item(0).getTextContent(), "server.env"); | ||
|
|
||
| // Make sure the server.env path exists. If not return null. | ||
| if (!Files.exists(serverEnvPath)) { |
There was a problem hiding this comment.
(Now I realize this might be superseded by my idea to wrap all this in a retry)
| if (debugPort == null) { | ||
| debugPort = port; | ||
| } | ||
|
|
There was a problem hiding this comment.
I appreciate how we guard this with the if (readDebugPort) flag and bypass reading the server.env file.
However, consider the case where we do a regular (non-debug) start/run, and then do a manual "Connect Liberty Debugger". If we do it too early, while dev mode is still starting, before the server is launched, then either reading the port from server.env, or even reading liberty-plugin-config.xml could fail.
Should we just add a sleep and retry on this path to handle this case?
If we can't, it might suggest we would then ideally want to disable to connect before the server is active. But maybe sleeping/retrying would be easier? WDYT?
| } | ||
|
|
||
| // Remove old debug target | ||
| launch.removeDebugTarget((IDebugTarget) object); |
There was a problem hiding this comment.
I noticed removeDebugTarget was spitting out a ClassCastException like:
java.lang.ClassCastException: class org.eclipse.debug.core.Launch cannot be cast to class org.eclipse.debug.core.model.IDebugTarget (org.eclipse.debug.core.Launch and org.eclipse.debug.core.model.IDebugTarget are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @2ee10074)
and presumably because of this the view wasn't looking as clean as ideally it would after doing disconnect and then (re)Connect
Fixes #498
This PR creates the following behaviors:
2. A restart of the server from dev mode via the command line will result in the debugger being disconnected and reconnected when the server restarts (using whatever debug port dev mode chose)3. When in debug mode, the debugger is always on.... if disconnected (automatically or manually), it will always attempt to reconnect.After reviewing, it seemed overkill to attempt to reconnect the debugger on every disconnect. This also created issues when intentionally disconnecting the debugger. In place of number 2 and 3 above, we are instead adding a "Connect Liberty Debugger" action to the Debug view context menu. If the debugger is disconnected (due to a restart of the server or manual disconnect), a user can now reconnect without having to stop and start the application via the Dashboard.
----- More Details ------
In the second rendition of the Liberty Tools debugger (prior to this PR), the debugger was combined with the Maven/devmode process into one launch configuration. This meant that the lifecycle of the two processes were tightly coupled causing undesired behavior. For example, a disconnect of the debugger triggered a full termination of the application running in Maven. 3 ways this disconnect could happen is either via a HCR failure, a restart of the server via devmode, or a manual disconnect via the debug view context menu.
This PR makes the following improvements: